© BUMDESREPUBLIK @ Offenlegungsschrift 

DEUTSCHLAMD @ <| Qg 43 £ 1 



® Int. CI. 7 : 

G 06 F 9/38 




DEUTSCHES 
PATENT- UND 
MARKENAMT 



® Aktenzeichen: 
@ Anmeldetag: 
(43) Offenlegungstag: 



198 43 640.8 
23. 9. 1998 
30. 3.2000 



CO 
00 



@ Anmelder: 


@ Erfinder: 


Siemens AG, 80333 Miinchen, DE 


Siemers, Christian, 25746 Heide, DE 




(S§) Entgegenhaltungen: 




DE 44 16 881 C2 




DE 196 54 846 A1 




US 48 70 302 




EP 08 25 540 A1 



Die folganden Angaben aind den vom Anmelder eingereichten Unterlagen e nt no m men 

Prufungsantrag gem. § 44 PatG ist gestellt 

® Verfahren zum Konfigurieren eines konfigurierbaren Hardware- Blocks 

® Die Hardware-Block-Konfigurierung erfolgt basierend 
auf Befehten Oder Befehlsfolgen, wobei jeweils die Schrit- 
te 

- Ermittlung der zur Ausfuhrung eines jeweiligen Befehls 
benotigten Art von Teileinheit des konfigurierbaren Hard- 
ware-Blocks, 

- Auswahl einer noch nicht anderweitig belegten Teilein- 
heit der zuvor ermittelten Art, und 

- Konfigurieren von um die ausgewahite Teileinheit her- 
um vorgesehenen konfigurierbaren Verbindungen 
ausgefuhrt werden. 



Normal* Befehle 


Oeatinatlon- 
Register 


Source- 
Register 1 


Source- 
Register 2 


Mnemonic 


0 




kd-Btte 


ksl-BUs 


ks2-Blts 


m-Bfts 




Bedfngte Befehie 


Destination- 
Register 


Source- 
Register 1 


Source. 
Register 2 


Mnemonic 


Bedlngungs- 
Flag 




kd-Blts 


ka1-Blts 


ks2-Bits 


m-Blts 


p-BKs 


pxx-Befehla 


Destination. 
Flag 


Source. 
Register 1 


Source- 
Register 2 


Mnemonic 


0 




p-Bitt 


ks 1-0 its 


ks2-BJta 


m-Brts 




loopxx-Befehle 


0 


Source- 
Register 1 


Source- 
Register 2 


Mnemonic 


0 






ksl-Stt* 


ks2-Bits 


m-etts 





CO 

00 
O) 



BUNDESDRUCKEREI 02.00 002 013/233/1 



13 



V 



DE 198 43 640 A 1 

Beschreibung 

Die vorliegende Erfindung betrifft ein Verfahren gemaB dem Oberbegriff des Patentanspruchs 1, d. h. ein Verfahren 
zum Konfigurieren eines konfigurierbaren Hardware-Blocks, so daB dieser durch Befehle oder Befehlsfolgen vorgege- 
5 bene arithmetische und/oder logische Operationen oder Operationsfolgen ausfiihren kann. 

Ein derartiges Verfahren wird unter andercm benotigt, um die sogenannte s-unit eines sogenannten >S<puters zu kon- 
figurieren. Ein >S<puter ist eine programmgesteuerte Einheit, die insbesondere durch die Verwendung eines konfigurier- 
baren Hardware-Blocks in dem die Befehle abarbeitenden Teil in der Lage ist, mehr als einen Befehl pro Prozessortakt 
auszufuhren. 

10 Ein solcher >S<puter ist beispielsweise aus der EP 0 825 540 Al bekannt. 

Der grundlegende Aufbau eines >S<puters ist in Fig, 11 gezeigt und wird nachfolgend unter Bezugnahme hierauf be- 
schrieben. 

Der Vollstandigkeit halber sei bereits an dieser Stelle darauf hingewiesen, daB der >S<puter, insbesondere dessen die 
Befehle abarbeitende Teil nur teilweise (nur so weit es fiir die vorliegend naher betrachteten konfigurierbaren Hardware- 

15 Bldcke und deren Konfigurierung von Bedeutung ist) dargcstellt und beschrieben ist. 

Der >S<puter gemaB Fig. 11 umfaBt eine Vordecodier-Einheit (predecode unit) 1, einen Instruktions-Puffer (instruc- 
tion buffer) 2, eine Decodier-, Umbenennungs- und Lade-Einheit (decode, rename & load unit) 3, die bereits erwahnte s- 
Paradigmen-Einheit (s-unit) 4, einen Daten-Cache (data cache) 5, und eine Speicher-Schnittstelle (memory interface) 6, 
wobei die s-unit 4 aus einem Strukturprogrammier-Puffer (programmable structure buffer) 41, einer Funktionseinheit mit 

20 programmierbarer Struktur (functional unit with programmable structure) 42, einem Integer/AdreBinstruktions-Puffer 
(integer/address instruction buffer) 43 und einem Registerblock (integer register file) 44 besteht. 

Die Besonderheit des >S<puters besteht insbesondere in dessen s-unit 4, genauer gesagt in der functional unit 42 der- 
selben. Die functional unit 42 ist eine konfigurierbare Hardware, die basierend auf vom >S<puter auszufuhrenden Befeh- 
len oder Befehlsfolgen dynamisch so konfigurierbar ist, daB sie die durch die Befehle oder Befehlsfolgen vorgegebenen 

25 Aktionen bzw. Operationen ausfiihren kann. 

Vom >S<puter auszufuhrende Instruktionen (genauer gesagt diese reprasentierende Code-Daten) gelangen aus einem 
nicht gezeigten Speicher iiber das memory interface 6 in die predecode unit 1, wo sie vordecodiert werden; dabei konnen 
zu den Code-Daten beispielsweise Informationen hinzugefugt werden, die die spatere Decodierung in der decode, re- 
name & load unit 3 erleichtem. Die Code-Daten gelangen dann iiber den instruction buffer 2 in die decode, rename & 

30 load unit 3, wo die Ausfuhrung der durch die Code-Daten reprasentierten Befehle vorbereitet wird. Diese Vbrbereitung 
umfaBt die Decodierung der Code-Daten, die Konfigurierung bzw. Strukturierung der functional unit 42, die Initialisie- 
rung bzw. Verwaltung des integer register file 44, und das Starten der wunschgemaB konfigurierten functional unit 42. 

Die Strukturierung bzw. Konfigurierung der functional unit 42 erfolgt unter Verwendung von die gewunschte Konfi- 
guration reprasentierenden Konfigurations-Daten, die von der decode, rename & load unit 3 in den programmable struc- 

35 ture buffer 41 geschriebcn werden. Diese, die gewunschte Konfiguration reprasentierenden Konfigurations-Daten wer- 
den in der decode, rename & load unit 3 kreiert; sie konnen aber auch schon in codierter Form in den Code-Daten ent- 
halten sein. 

Die functional unit 42 ist dazu ausgelegt, Daten aus dem register file 44 und/oder dem data cache 5 auszulesen, die aus- 
gelesenen Daten arithmetisch und/oder logisch zu verarbeiten, und das Ergebnis der Verarbeitung reprasentierende Daten 
40 in das register file 44 und/oder den data cache 5 einzuschreiben. 

Bei geeigneter Initialisierung des register file 44 und bei geeigneter Konfigurierung der functional unit 42 hat der Be- 
trieb der functional unit 42 die Ausfuhrung der Operationen zu Folge, die durch die Ausfuhrung der Befehle, auf der Ba- 
sis welcher die Initialisierung des register file 44 und die Konfigurierung der functional unit 42 erfolgten, zu bewirken 
sind. 

45 Die Vornahme der durch die Ausfuhrung von Instruktionen zu bewirkenden Aktionen durch eine entsprechend konfi- 
gurierte Hardware (die functional unit 42) ist bekanntlich bedeutend schneller als die Ausfuhrung der Befehle in den 
"normalen" Arithmetisch/Logischen Einheiten (ALUs) von herkommlichen programrngesteuerten Einheiten. Dies gilt in 
besonderem MaBe fiir den Fall, daB die Hardware (die functional unit 42) so konfiguriert ist, daB durch deren Betrieb ein 
Ergebnis erzielbar ist, das der Ausfuhrung mehrerer aufeinanderfolgender Befehle (eines mehrere Befehle umfassenden 

50 Makrobefehls) entspricht. 

Beziiglich weiterer Einzelheiten zum Aufbau, der Funktion und der Wirkungsweise von >S<putern und der darin ent- 
haltenen konfigurierbaren Hardware wird auf die vorstehend bereits erwahnte EP 0 825 540 Al verwiesen. 

Der Vollstandigkeit halber sei angemerkt, daB nicht alle Aktionen, die durch die vom >S<puter auszufuhrenden Be- 
fehle zu bewirken sind, durch die functional unit 42 ausfuhrbar sind. Befehle wie insbesondere zur Programmablauf- 

55 steuerung bzw. Kon troll fluBsteuerung dienende Befehle wie beispielsweise Branch-, Jump-, No- Operation-, Wait- und 
Stop-Befehle werden in der Regel auf herkommliche Art und Weise ausgefuhrt werden. 

Nichtsdestotrotz kann durch die Verwendung konfigurierbarer Hardware-Blocke wie der functional unit 42 im allge- 
meinen eine hohere Anzahl von durch auszufuhrende Befehle zu bewirkenden Aktionen pro Zeiteinheit ausgefuhrt wer- 
den als es mit herkoinmlichen programmgesteuerten Einheiten der Fall ist, also mehr als ein Befehl pro Prozessortakt ab- 

60 gearbeitet werden. 

Voraussetzung ist naturlich, daB die Hardware-Blocke schnell konfiguriert und effizient genutzt werden. 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, das Verfahren gemaB dem Oberbegriff des Patentan- 
spruchs 1 derart weiterzubilden, daB die Hardware-Blocke schnell konfigurierbar und effizient nutzbar sind. 

Diese Aufgabe wird erfindungsgemaB durch die im kennzeichnenden Teil der Patentanspruchs 1 beanspruchten Merk- 
65 male gelost. Demnach ist vorgesehen, daB fur die Umsetzung der abzuarbeitenden befehle in eine Hardware-Block- 
Struktur die Schritte 

- Ermittlung der zur Ausfuhrung eines jeweiligen Befehls benotigten Art von Teileinheit des konfigurierbaren 
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Hardware-Blocks, 

- Auswahl einer noch nicht anderweitig belegten Teileinheit der zuvor ermittelten Art, und - sofern eine solche 
Teileinheit gefunden werden konnte - 

- Konfigurieren von um die ausgewahlte Teileinheit herum vorgesehenen konfigurierbaren Verbindungen 

5 

ausgefuhrt werden. 

Durch eine derartige Vorgehensweise lassen sich zu konfigurierende Hardware-Blocke mit minimalem Aufwand au- 
tomatisch konfigurieren. Die Konfiguration erfolgt dabei sehr schnell und nutzt die Komponenten des Hardware-Blocks 
optimal aus; so konfigurierte Hardware-Blocke lassen sich sehr effizient einsetzen. 

Vorteilhafte Weiterbildungen der Erfindung sind den Unteranspriichen, der nachfolgenden Beschreibung und den Fi- 10 
guren entnehmbar. 

Die Erfindung wird nachfolgend anhand von Ausfuhrungsbeispielen unter Bezugnahme auf die Figuren naher erlau- 
tert. Es zeigen 

Fig. 1 A bis ID ein Beispiel fur einheitliche Befehls-Formate, die die umzusetzenden Befehle im betrachteten Bei spiel 
aufweisen sollten oder in die sie vor Beginn der Umsetzung vorzugsweise gebracht werden, 15 
Fig. 2 eine bei der hardwaremaBigen Realisierung der Umsetzung verwendete Look-Up-Table, 
Fig. 3A und 3B das Format der aus der Look-Up- Table gemaB Fig. 2 ausgegebenen Daten, 

Fig. 4 das Blockschaltbild einer Schaltung zur Auswahl und Konfigurierung einer zur Ausfuhrung eines Befehls be- 
notigten Teileinheit des Hardware-Blocks, 

Fig. 5 das Blockschaltbild einer Schaltung zur Festlegung der Daten- und/oder Signalqueilen und der Daten- und/oder 20 
Signalziele fur die durch die Schaltung gemaB Fig. 4 ausgewahlte Teileinheit, 

Fig. 6 das Blockschaltbild einer Schaltung zur Handhabung von in den umzusetzenden Befehlen enthaltenen Konstan- 
ten, 

Fig. 7 das Blockschaltbild einer Schaltung zur Durchfiihrung des sogenannten Data Forwarding, 

Fig. 8 einen sogenannten Cross-Bar-Switch zum Einschreiben der Konfigurations-Daten in einen tcmporaren Bit- 25 
Strom, 

Fig. 9 eine Anordnung zum Einschleusen des temporaren Bitstroms in einen Hauptbitstrom, 

Fig. 10 eine komplette Anordnung zum Umsetzen von Befehlen in Konfigurations-Daten zur wunschgemaBen Konfi- 
gurierung des Hardware-Blocks, 

Fig. 11 den prinzipiellen Aufbau eines >S<puters, und 30 

Fig. 12 den prinzipiellen Aufbau eines Hardware-Blocks der vorliegend naher betrachteten Art. 

Zur Erleichterung des Verstandnisses wird zunachst der prinzipielle Aufbau eines Hardware-Blocks beschrieben, der 
durch das danach beschriebene Verfahren konfigurierbar sein soil. 

Der prinzipielle Aufbau eines solchen Hardware-Blocks ist in Fig. 12 gezeigt. Der gezeigte Hardware-Block ist dazu 
ausgelegt ist, abhangig von seiner Konfigurierung in einer Speichereinrichtung gespeicherte Daten auszulesen, die aus- 35 
gelesenen Daten arithmetisch und/oder logisch zu verarbeiten und das Ergebnis der Verarbeitung reprasentierende Daten 
in die Speichereinrichtung einzuschreiben; er ist beispielsweise als die functional unit 42 des >S<puters gemaB Fig. 1 1 
einsetzbar. 

Die Speichereinrichtung, aus welcher der konfigurierbare Hardware-Block Daten ausliest und in welche der Hard- 
ware-Block Daten einschreibt, kann innerhalb oder auBerhalb des Hardware-Blocks vorgesehen sein; im vorliegend be- 40 
trachteten Beispiel wird die Speichereinrichtung durch das register file 44 des >S<puters gemaB Fig. 11 gebildet. Der 
Hardware-Block ist ein asynchrones Schaltnetz zwischen den Aus- und Eingangen der Speichereinrichtung; die Bestand- 
teile des Hardware-Blocks sind asynchron miteinander gekoppelt. 

Die Speichereinrichtung ist vorzugsweise von auBerhalb des Hardware-Blocks vor der Inbetriebnahme desselben in- 
itialisicrbar; denkbar ware auch, daB der Hardware-Block die Initialisierung der Speichereinrichtung selbst veranlaBt 45 
oder durchfuhrt. 

Der in der Fig. 12 gezeigte Hardware-Block weist eine oder mehrere arithmetische Einheiten AU1, AU2, eine oder 
mehrere Vergleichs-Einheiten CU, einen oder mehrere Multiplexer eines ersten lyps MUXA1, MUXA2, MUXA3, einen 
oder mehrere Multiplexer eines zweiten lyps MUXB, und einen oder mehrere Demultiplexer DEMUX auf. 

Die arithmetischen Einheiten AU1, AU2 weisen im betrachteten Beispiel zwei Eingangsanschlusse, einen Ausgangs- 50 
anschluB und einen SteueranschluB auf. Den arithmetischen Einheiten AU1, AU2 obliegt es, die uber deren Eingangsan- 
schlusse eingegebenen Eingangssignale arithmetisch und/oder logisch zu verarbeiten. Die Operationen, die durch die 
arithmetischen Einheiten AU1, AU2 ausfuhrbar sind, konnen fest vorgegeben oder individuell einstellbar (konfigurier- 
bar) sein; sie umfassen insbesondere arithmetische Operationen wie Addition, Subtraktion, Multiplikation, Division etc., 
logische Verkniipfungen wie UND-Verkniipfungen, ODER-Verkniipfungen, Invertierung, Komplemcntbildung etc., 55 
arithmetische und logische Shift-Operationen, und Datentransfers (Durchschaltung eines der eingegebenen Signale zum 
AusgangsanschluB). Die arithmetischen Einheiten AU1, AU2 sind nicht mit den Arithmetisch/Logischen Einheiten 
(ALUs) herkommlicher programmgesteuerter Einheiten wie Mikroprozessoren, Mikrocontrollern etc. gleichzusetzen; 
die von ihnen ausfuhrbaren Operationen sind begrenzt, so dafi der Aufbau der arithmetischen Einheiten AU1, AU2 ver- 
gleichsweise einfach bleiben kann. Uber die Steueranschliisse der arithmetischen Einheiten AU1, AU2 ist fcstlegbar, ob 60 
die betreffende arithmetische Einheit die Operation, zu deren Ausfuhrung sie vorgesehen ist, ausfuhrt oder nicht. Dies er- 
moglicht die praktische Umsetzung von Befehlen, deren Ausfuhrung vom Vorliegen einer bestimmten Bedingung ab- 
hangt. Die Bedingung kann beispielsweise der Zustand eines bestimmten Rags sein: ist das Flag gesetzt, wird die der be- 
treffenden arithmetischen Einheit obliegende Aufgabe (beispielsweise eine Addition) ausgefuhrt, andernfalls nicht (oder 
umgekehrt). Derartige, nachfolgend als "konditionierte Befehle" bezeichnete Befehle ermoglichen es, die schwer hand- 65 
habbaren bedingten Sprungbefehle zu eliminieren; sie werden spater noch genauer beschrieben. 

Die Vergleichs-Einheit CU weist im betrachteten Beispiel zwei Eingangsanschlusse und einen AusgangsanschluB auf. 
Der Vergleichs-Einheit CU obliegt es, die an deren Eingangsanschliissen anliegenden Signale oder Daten \fergleichsope- 
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rationen zu unterziehen. Die Operationen, die durch die Vergleichs-Einheit CU ausfuhrbar sind, konnen fest vorgegeben 
oder individuell einstellbar (konfigurierbar) sein; sie umfassen beispielsweise GroBer-, GrdBer/Gleich-, Kleiner-, Klei- 
ner/Gleich-, Gleich-, und Ungleich-Vergleiche und Xjberpriifungen auf wahr (TRUE) und unwahr (FALSE). Der Aus- 
gangsanschluB der Vergleichs-Einheit CU ist iiber den nachfolgend noch genauer beschriebenen Demultiplexer DEMUX 
5 mit den Stcueranschlussen der arithmetischen Einheiten AU1, AU2 verbunden. Vom Ergcbnis der in der Vergleichs-Ein- 
heit CU ausgcfuhrten Operation hangt es also ab, ob die arithmetischen Einheiten AU1, AU2 die Operation, zu dcren 
Ausfuhrung sie vorgesehen sind, ausfuhren oder nicht. 

Die Multiplexer des ersten Typs MUXA1, MUXA2, MUXA3, der Multiplexer des zweiten Typs MUXB, und der De- 
multiplexer DEMUX dienen zur Auswahl der Daten- und/oder Signalquellen und der Daten- und/oder Signalziele. Ge- 
10 nauer gesagt dienen 

- der Multiplexer MUXA1 zur Auswahl der Quellen der den Eingangs an senilis sen der arithmetischen Einheit AU1 
zugefuhrten Daten und/oder Signale (mogliche Daten- und/oder Signalquellen sind im betrachteten Beispiel das re- 
gister file 44 und andere arithmetische Einheiten), 

15 - der Multiplexer MUXA2 zur Auswahl der Quellen der den Eingangsanschliissen der arithmetischen Einheit AU2 

zugefuhrten Daten und/oder Signale (mogliche Daten- und/oder Signalquellen sind im betrachteten Beispiel das re- 
gister file 44 und andere arithmetische Einheiten), 

- der Multiplexer MUXA3 zur Auswahl der Quellen der den Eingangsanschliissen der Vergleichs-Einheit CU zu- 
gefuhrten Daten und/oder Signale (mogliche Daten- und/oder Signalquellen sind im betrachteten Beispiel das regi- 

20 ster file 44 und die arithmetischen Einheiten), 

- der Multiplexer MUXB zur Auswahl der Quellen der dem register file zugefuhrten Daten und/oder Signale (mog- 
liche Daten- und/oder Signalquellen sind im betrachteten Beispiel die arithmetischen Einheiten und/oder das regi- 
ster file selbst), 

- der Demultiplexer DEMUX zur Auswahl des oder der Ziele fur die von der Vergleichs-Einheit CU ausgegebenen 
25 Daten und/oder Signale (mogliche Daten- und/oder Signalziele sind im betrachteten Beispiel die arithmetischen 

Einheiten). 

Die Multiplexer des ersten Typs weisen mehrere Eingangsanschliisse und zwei Ausgangsanschlusse auf, die Multiple- 
xer des zweiten Typs mehrere Eingangsanschlusse und einen AusgangsanschluB, und der Demultiplexer einen Eingangs- 

30 anschluB und mehrere Ausgangsanschliissc. 

Die Multiplexer und der Demultiplexer weisen in der Fig. 12 nicht gezeigte Steueranschliisse auf, iiber welche ein- 
stellbar ist, welche Eingangsdaten und/oder -signale auf welche Ausgangsanschlusse durchgeschaltet werden. Die An- 
zahl der Steueranschliisse hangt von der erforder lichen Anzahl der verschiedenen Zuordnungs-Kombinationen ab; bei 32 
Eingangsanschliissen und zwei Ausgangsanschlussen sind beispielsweise 10 Steueranschliisse erforderlich, um an belie- 

35 bigen Eingangsanschliissen anliegende Signale und/oder Daten auf beliebige Ausgangsanschlusse durchschalten zu kon- 
nen. Im Fall des Einsatzes des Hardware-Blocks als functional unit 42 im >S<puter gemaG Fig. 11 sind die Steuersignal- 
anschliisse vorzugsweise mit dem programmable structure buffer 41 verbunden, so dafi die in diesen eingeschriebenen 
Konfigurations-Daten im wesentlichen unmittelbar zur Multiplexer- Ansteuerung verwendbar sind. Die im programma- 
ble structure buffer 41 gespeicherten Konfigurations-Daten umfassen vorzugsweise auch die Konfigurations-Daten zur 

40 Festlegung der jeweiligen Funktion cer arithmetischen Einheiten AU1, AU2 und der Vergleichs-Einheit CU. 

Durch die arithmetischen Einheiten AU1, AU2, die Vergleichs-Einheit CU, die Multiplexer des ersten Typs MUXA1, 
MUXA2, MUXA3, den Multiplexer des zweiten Typs MUXB, und den Demultiplexer DEMUX wird der Hardware- 
Block in die Lage versetzt, in einer Speichereinrichtung (im register file 44) gespeicherte Daten auszulesen, die ausgele- 
senen Daten arithmetisch und/oder logisch zu verarbeiten und das Ergebnis der Verarbeitung reprasentierende Daten in 

45 die Speichereinrichtung (das register file 44) einzuschreiben. 

Der in Fig. 12 gezeigte und unter Bezugnahme darauf beschriebene Hardware-Block ist nur zur Erlauterung des 
grundlegenden Aufbaus gedacht. In der Praxis werden die arithmetische Einheiten, die \fergleichs-Einheiten, die Multi- 
plexer, und die Demultiplexer in einer deutlich groBeren Anzahl vorgesehen werden als es beim Beispiel gemaB Fig. 12 
der Fall ist. Der Hardware-Block ist vorzugsweise so dirnensioniert, daB normalerweise sanidiche Operationen, die von 

50 cinem spater noch naher beschriebenen, sogenannten Hyperblock zu bewirken sind, auf ein Mai in ihn einprogrammier- 
bar sind. 

Die im Hardware-Block vorgesehenen Daten- und/oder Signalpfade konnen durch einzelne Leitungen oder durch 
Busse gebildet werden, wobei es sich als vorteilhaft erweisen kann, wenn in den einzelnen Teileinheiten des Hardware- 
Blocks oder im Bus-System konfigurierbar ist, wie viele und/oder welche Busleitungen zu beriicksichtigen sind. 

55 Die Konfigurierung eines Hardware-Blocks nach Art der Fig. 12 kann basierend auf Befehlcn oder Befehlsfolgen er- 
folgen. Setzt man Befehle oder Befehlsfolgen in entsprechende Hardware-Block-Strukturen um, so ist der so konfigu- 
rierte Hardware-Block als Ablaufeinheit fur sequenuelle Befehlsfolgen nutzbar. Diese Form der Hardware-Block-Kon- 
figurierung wird nachfolgend auch als struktur-prozedurale Programmierung bezeichnet. 

Ausgangspunkt fur die struktur-prozedurale Programmierung kann ein in einer Hochsprache wie beispielsweise C, 

60 C++ etc. geschriebenes Programm sein. Dieses Programm wird durch einen Compiler ubersetzt, und der dabei erhaltene 
Code wird (vorzugsweise hyperblock-weise) in Strukturinformationen umgesetzt, basierend auf welcher der zu konfigu- 
rierende Hardware-Block konfigurierbar ist. Was unter einem Hyperblock zu verstehen ist, wird spater noch genauer be- 
schrieben werden. 

Ausgangspunkt fiir die struktur-prozedurale Programmierung kann selbstverstandlich auch ein in Assembler geschrie- 
65 benes oder sonstiges Programm sein. Die Art und Weise der Programmierung (funktional, imperativ, objekt-orien- 
tiert, . . .) ist ebenfalls keinen Einschrankungen unterworfen. 

Es erweist sich als vorteilhaft wenn der in die Strukturinformation umzusetzende Code, also die durch den Compiler 
oder auf andere Art und Weise erzeugten Maschinenbefehle nur bestimmte Maschinenbefehl-Typen, namlich unkondi- 
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tionierte Befehle, konditionierte Befehle, Predicate-Befehle, und Loop-Befehle umfassen. Dann lassen sich in der Regel 
besonders lange (besonders viele Befehle enthaitende) Befehls-Bldcke mit nur einem Eintrittspunkt und nur einem Aus- 
trittspunkt bilden. Die Generierbarkeit von moglichst langen Befehls-Blocken mit nur einem Eintrittspunkt und nur ei- 
nem Austrittspunkt ist sehr bedeutsam, weil sich Befehle, die ein- und dem selben Befehls-Block angehoren, und zwar 
nur solche Befehle, als eine Einheit (als eine sich aus mehreren Befehlen zusammensetzende Makroinstruktion) behan- 5 
deln lassen, die in eine gemeinsame Hardware- Block- Struktur umgesetzt und auf ein Mai ausgefuhrt werden kann. Legt 
man der Konfigurierung eines Hardware-Blocks jeweils genau eine solche Einheit zugrunde (und ist der Hardware-Block 
groB genug, um so konfiguriert werden zu konnen), so laBt sich die Anzahl der zur Abarbeitung eines Programms erfor- 
derlichen Umstrukturierungen bzw. Umkonfigurierungen des Hardware-Blocks auf ein Minimum reduzieren. Die Be- 
fehls-Blocke, deren Generierung derzeit favorisiert wird, und deren Bildung durch die vorstehend genannten Befehls- 10 
gruppen auch moglich ist, sind die vorstehend bereits erwahnten Hyperblocke. 

Hyperblocke zeichnen sich insbesondere dadurch aus, daB bedingte Sprungbefehle unter Anwendung der nachfolgend 
noch naher beschriebenen sogenannten if-Kon version eliminiert werden. 

Beziiglich weiterer Einzelheiten zu den Hyperblocken, anderen Befehls-Blocken und damit in Zusammenhang stehen- 
den Themen wird auf 15 
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verwiesen. 

Die vorstehend erwahnten unkonditionierten Befehle sind Befehle zur bedingungslosen Bearbeitung von Daten ein- 
schlieBlich der Kopie von Daten von einem Speicherbereich in einen anderen (von einem Register in ein anderes). Diese 
Befehle werden im folgenden als normale Befehle bezeichnet. Sie umfassen arithmetische und logische Verknupfungen 30 
zwischen Daten zu neuen Werten und die sogenannten Move-Befehle zur Kopie von Registerinhalten. Das allgemeine 
Format dieser Befehle lautet: <Mnemonic> <Ziel-Register>, <Queilen-Register 1>, <Quellen- Register 2>. Zur Durch- 
fiihrung der durch einen solchen Befehl spezifizierten Operation wird normalerweise eine arithmetische Einheit des 
Hardware-Blocks benotigt. 

Die konditionierten Befehle sind Befehle zur Bearbeitung von Daten bei Vorliegen einer bestimmten Bedingung (Kon- 35 
dition). Die durch diese Befehle auszufiihrenden Aktionen entsprechen den durch die normalen Befehle ausfuhrbaren 
Aktionen, wobei die Ausfuhrung der betreffenden Aktionen jedoch von einer vorbestimmten Bedingung abhangt. Ist die 
Bedingung erfullt, wird die durch den Befehl spezifizierte Aktion ausgefuhrt, anderenfalls wird nichts ausgefuhrt (der be- 
treffende Befehl wirkt dann wie ein NOP-Befehl). Diese Befehle werden im folgenden als bedingte Befehle bezeichnet. 
Das allgemeine Format dieser Befehle lautet: <Mnemonic>p <Ziel-Register>, <Quellen-Register 1>, <Quellen-Register 40 
2> <p-Rag>, wobei durch das "p" am Ende des Mnemonic die Abhangigkeit der Befehls ausfuhrung von einer Bedin- 
gung signalisiert wird, und wobei die Bedingung durch einen bestimmten Zustand eines bestimmten Rags (des "p-Flag") 
definiert wird. Zur Durchfuhrung der durch einen solchen Befehl spezifizierten Operation wird normalerweise eine arith- 
metische Einheit des Hardware-Blocks benotigt; zur tjberprufung der Bedingung wird eine Vergleichs-Einheit benotigt, 
deren Ausgang mit dem Steuereingang der arithmetischen Einheit verbindbar ist. 45 

Die Predicate-Befehle sind Befehle zur Festlegung des Zustandes des in den bedingten Befehlen verwendeten Bedin- 
gungs-Flags (des p-Rags). Die Festlegung erfolgt dabei wahrend des Programmablaufs basierend auf einem \ergleich 
von zwei Daten. Diese Befehle werden im folgenden als pxx-Befehle bezeichnet. Das allgemeine Format dieser Befehle 
lautet: pxx <Quellen-Register 1>, <Quellen-Register 2>, <p-Rag>, wobei xx die durchzufuhrende Vergleichsoperation 
spezifiziert und durch gt (groBer als), ge (groBer oder gleich), eq (gleich), ne (ungieich), le (kleiner oder gleich) oder It 50 
(kleiner als) zu ersetzen ist. Die pxx-Befehle sind mit den ublichen Branch-Befehlen vergleichbar und dienen zum Ersatz 
derselben durch die Anwendung der sogenannten if- Kon version (siehe hierzu den vorstehend bereits erwahnten Aufsatz 
von Wen-Mei W. Hwu et al.). 

Die Loop-Befehle sind zur Schleifenwiederholung dienende Befehle am Ende eines Hyperblocks. Sie veranlassen ei- 
nen Rucksprung an den Anfang des betreffenden Hyperblocks, falls eine im Befehl spezifizierte Bedingung erfullt ist; sie 55 
konnen die Generierung eines READY-Signals veranlassen, wenn die Bedingung nicht mehr erfullt ist. Die Bedingung 
ist durch ein bestimmtes Ergebnis einer Vergleichsoperation definiert. Das allgemeine Format dieser Befehle lautet: 
loopxx <Quellen-Register 1>, <Quellen-Register 2>, wobei xx die durchzufuhrende Vergleichsoperation spezifiziert. 

Wie aus den Formaten der genannten Befehlstypen ersichtlich ist, werden als Daten- und/oder Signalquellen und Da- 
ten- und/oder Signalziele jeweils Register verwendet. Dies erweist sich bei Verwendung von Hardware-Blocken nach 60 
Art der Fig. 12 als besonders vorteilhaft, weil auf die Register (das register file 44) besonders effizient zugegriffen wer- 
den kann. Prinzipiell konnten aber auch Befehle zugelassen werden, deren Daten- und/oder Signalquellen und Daten- 
und/oder Signalziele keine Register sind. 

Viele Programme oder wenigstens groBe Teile von diesen konnen unter ausschlieBlicher Verwendung der vorstehend 
erlauterten Befehls-iypen geschrieben oder in solche Programme ubersetzt werden und mithin vollstandig in einen 65 
Hardware-Block der in der Fig. 12 gezeigten Art zur Ausfuhrung gebracht werden. Die Verwendung derartiger Hard- 
ware-Blocke in programmgesteuerten Einheiten kann deren Leistungsfahigkeit daher erheblich steigern. Hardware- 
Blocke der in der Fig. 12 gezeigten Art konnen jedoch auch auBerhalb programmgesteuerter Einheiten als eigenstandige 
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Einrichtungen zum Einsatz kommen und dann ebenfalls basierend auf Befehlen oder Befehlsstromen konfiguriert wer- 
den. 

Im folgenden wird nunmehr die Konfigurierung eines Hardware-Blocks beschrieben, durch welche dieser durch Be- 
fehle oder Befehlsfolgen vorgegebene arithmetische und/oder logische Operationen oder Operationsfolgen ausfiihren 
5 kann. 

Der Hardware-Block, genauer gesagt dessen Teileinheiten (arithmetische Einheiten, Vergleichs-Einhciten, Multiple- 
xer, Demultiplexer . . .) und die Verbindungen zwischen den Teileinheiten werden im betrachteten Beispiel durch die ge- 
wunschte Konfiguration reprasentierenden Konfigurations-Daten (Konfigurations-Bits) konfiguriert. Dementsprechend 
ist es die Aufgabe des nachfolgend beschriebenen Konfigurations-Verfahrens, die Konfigurations-Daten bzw. einen diese 
10 enthaltenden Bitstrom basierend auf den der Hardware-Block- Konfiguration zugrundezulegenden Befehlen oder Be- 
fehlsfolgen zu generieren oder zu variieren. 

Im betrachteten Beispiel wird davon ausgegangen, daB ausschlieBlich die vorstehend genannten Typen von Befehlen, 
d. h. normale Befehle, bedingte Befehle, pxx-Befehle und loopxx-Befehle umgesetzt werden; andere Befehle mussen an- 
derweitig ausgeftihrt werden, beispielsweise durch die Ausfuhrungseinheit einer herkommlichen programmgesteuerten 
15 Einheit. 

Fiir die Umsetzung der umsetzbaren Befehle in entsprechende Hardware-Block-Strukturen kann es sich als vorteilhaft 
erweisen, wenn die Befehle von Haus aus ein in den Fig. 1A (normale Befehle), IB (bedingte Befehle), 1C (pxx-Be- 
fehle), und ID (loopxx-Befehle) beispielhaft veranschaulichtes einheitliches Format aufweisen oder durch einen Deco- 
dierer in ein solches Format gebracht werden. 

20 Insbesondere wenn die Teileinheiten des Hardware-Blocks konfigurierbar sind, werden diesen (physikalischen) Teil- 
einheiten logische bzw. virtuelle Einheiten zugeordnet, wobei die virtuellen Einheiten die verschiedenen Funktionen der 
physikalischen Teileinheiten angeben. Der physikalischen Teileinheit "erste arithmetische Einheit AU1" konnen - sofern 
diese konfigurierbar ist - beispielsweise die virtuellen Einheiten Addierer, Subtrahierer etc. zugeordnet sein. Eine virtu- 
elle Einheit ist genau einer physikalischen Teileinheit zugeordnet, aber einer physikalischen Teileinheit konnen mehrere 

25 virtuelle Einheiten zugeordnet sein. Samtliche virtuellen Einheiten werden vorzugsweise in einer Tabellc oder Liste ver- 
waltet. Die jeweiligen Eintrage enthalten neben Informationen zu den virtuellen Einheiten selbst auch Information dar- 
uber, welcher physikalischen Teileinheit die jeweiligen virtuellen Einheiten zugeordnet sind, uber welche Konfigurati- 
ons-Bits und wie diese physikalische Teileinheit gegebenenfalls konfiguriert werden muB, um ihr die durch die virtuelle 
Einheit reprasentierte Funktion zu verleihen. 

30 Vorzugsweise wird ein kompletter Hyperblock in eine Hardware-Block-Struktur umgesetzt. 

Die Umsetzung eines Befehls in eine Hardware- Block- Strukturierungsinformationen erfolgt im wesentlichen in drei 
Phasen. 

In der ersten Phase wird zunachst errnittelt, welcher TVP von virtueller Einheit (Addierer, Subtrahierer, Multiplizierer 
. . .) zur Ausfuhrung der betreffenden Instruktion benotigt wird, und ob eine solche virtuelle Einheit noch verfugbar ist. 

35 Ist noch eine virtuelle Einheit des benotigten Typs frei, so wird diese oder eine von diesen zur Ausfuhrung der betreffen- 
den Instruktion ausgewahlt. Sodann erfolgen die Konfiguration oder deren Vorbereitung und eine Reservierung der der 
ausgewahlten virtuellen Einheit zugeordneten physikalischen Teileinheit. Zur Konfiguration werden einfach die der be- 
treffenden physikalischen Teileinheit zugeordneten Konfigurations-Bits gesetzt oder zuriickgesetzt; dies bereitet keine 
Schwierigkeiten, denn die Informationen, welcher physikalischen Teileinheit die ausgewahlte virtuelle Einheit zugeord- 

40 net ist, uber welche Konfigurations-Bits und wie diese physikalische Teileinheit gegebenenfalls zu konfigurieren ist, wer- 
den ja zusammen mit der virtuellen Einheit verwaltet. Die Reservierung der der ausgewahlten virtuellen Einheit zuge- 
ordneten physikalischen Teileinheit ist notwendig, um zu verhindern, daB die betreffende physikalische Teileinheit mehr- 
fach verwendet werden kann. Im betrachteten Beispiel wird dies dadurch bewerkstelligt, daB nach jeder Vergabe einer 
physikalischen Teileinheit fur einen bestimmten Zweck samtliche virtuellen Einheiten, die der betreffenden physikali- 

45 schen Teileinheit zugeordnet sind, gesperrt werden. 

Bei pxx-Befehlen kann es je nach dem Aufbau des Hardware-Blocks erforderlich sein, abhangig vom p-Flag eine ganz 
bestimmte physikalische Teileinheit (Vergleichs-Einheit) auszuwahlen. 

Bei bedingten Befehlen wirkt sich das p-Flag nur dann auf die Auswahl der virtuellen/physikalischen Einheit(en) aus, 
wenn bestimmte Instruktionen nur mit bestimmten Flags moglich sind, also keine vollstandige Orthogonalitat in dem 

50 Teilbefehlssatz fur bedingte Befehle vorhanden ist. 

In der zweiten Phase der Hardware-Block- Konfigurierung werden die den ausgewahlten physikalischen Teileinheiten 
vor- und/oder nachgeschalteten Multiplexer konfiguriert, um die Daten- und/oder Signalquellen und die Daten- und/oder 
Signalziele entsprechend den Festlegungen in den umzusetzenden Instruktionen einzustellen. Die Multiplexer und das 
Format der umzusetzenden Instruktionen sind im Idealfall so aneinander angepaBt, daB die die Daten- und/oder Signal- 

55 qucllen und die die Daten- und/oder Signalziele festlegenden Teile der Instruktionen unverandert als die die Multiplexer 
konfigurierenden Konfigurations-Bits ubernommen werden konnen. Ist dies - aus welchem Grund auch immer - nicht 
moglich, konnen die die Multiplexer konfigurierenden Konfigurations-Bits beispielsweise einer Tabelle entnommen 
werden, in welcher die Zuordnung zwischen den die Daten- und/oder Signalquellen und die Daten- und/oder Signalziele 
festlegenden Teilen der Instruktionen und den die Multiplexer konfigurierenden Konfigurations-Bits gespeicherl ist. Die 

60 Konfigurierung, die erforderlich ist, um eine Verbindung zu einer bestimmten Daten- und/oder Signalquelle und/oder zu 
einem bestimmten Daten- und/oder Signalziel herzustellen, ist vorzugsweise fur alle Multiplexer gleich. 

Eine gesonderte Behandlung ist notwendig, wenn die der auszufuhrenden Operation zugrundezulegenden Daten zu- 
mindest teilweise aus einer im Instruktions-Code enthaltenen Konstanten bestehen. Dann muB 

65 - ein freies (Konstanten-)Register gesucht werden, 

- dieses Register als Daten- und/oder Signalquelle verwendet werden, und 

- die im Instruktions-Code enthaltene Konstante vor der Inbetriebnahme des UCB in das ausgewahlte Register ein- 
geschrieben werden. 
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Im betrachteten Beispiel wird vorab uberpriift, ob die betreffende Konstante schon in einem (Konstanten-)Register ge- 
speichert ist. Ergibt sich dabei, daB bereits ein die Konstante enthaltendes (Konstanten-)Register existiert, so wird dieses 
schon existierende (Konstanten-)Register als Daten- und/oder Signalquelle verwendet. 

Zu beachten ist ferner, daB die umzusetzenden Instruktionen un terse hiedlich viele Daten- und/oder Signalquellen und 5 
Daten- und/oder Signalziele aufweisen und/oder von Bedingungen abhangen und insofern eine Sonderbehandlung der 
einzelnen Instruktionen erforderlich ist. 

Als Daten- und/oder Signalziel verwendete Register werden ubrigens als belegt markiert, da innerhalb eines Hyper- 
blocks keine Zweitbelegung zulassig ist und durch ein sogenanntes (Runtime) Register Renaming, einer aus superskala- 
ren Architekturen bekannten Technologie, verhindert werden muB. 10 

Nach dieser (fur alle Befehle gemeinsamen) zweiten Phase werden fur einzelne Befehlstypen spezielle Teilschritte 
eingefiigt, die sich aus den jeweiligen Besonderheiten ergeben. 

Unter anderem muB bei bedingten Befehlen die das Vorliegen der Bedingung uberprufende Vergleichs-Einheit ermit- 
telt werden und deren Ausgangssignal uber den zugehdrigen Demultiplexer auf die die Operation ausfuhrende arithme- 
tische Einheit geschaltet werden. Ferner ist zu beriicksichtigen, welcher Art die Bedingung ist. 15 

Bei bedingten Move-Befehlen ist zusatzlich dafur Sorge zu tragen, daB der Inhalt des Zielregisters bei Nicht.- Ausfuh- 
rung des Befehls nicht verandert wird. 

Nach der zweiten Phase der Hardware-Block-Konfigurierung konnte diese beendet und der Hardware-Block gestartet 
werden. Dies geschieht vorzugsweise jedoch erst nach der Ausfuhrung der nachfolgend beschriebenen dritten Phase. 

In dieser dritten Phase der Hardware-Block-Konfigurierung wird ein sogenanntes data forwarding reaiisiert, Dabei 20 
werden als Daten- und/oder Signalquellen nicht stur die in den In-struktionen angegebenen Daten- und/oder Signalquel- 
len verwendet, sondern nach Moglichkeit die physikalische Teileinheit, die die betreffende Daten- und/oder Signalquelle 
innerhalb des jeweiligen Hyperblocks zuvor zu beschreiben hatte. Dies erweist sich in zweifacher Hinsicht als vorteil- 
haft: einerseits, weil eventuell weniger Register benotigt werden (wenn die in der Instruktion angegebene Daten- und/ 
oder Signalquelle nicht als solche verwendet wird, muB sie auch nicht beschrieben werden und kann gegebenen falls ganz 25 
weggelassen werden), und andererseits, weil die benotigten Daten bei Abholung von der diese erzeugenden Teileinheit 
(beispielsweise einer arithmetischen Einheit) friiher verfugbar sind als wenn sie zuerst in ein Register geschrieben und 
von dort abgeholt werden mussen. Das data forwarding kann bei alien Befehlen zur Anwendung kommen und erweist 
sich im Durchschnitt als enormer Vorteil. 

Das soeben kurz in Worten beschriebene Verfahren laBt sich auch durch dessen softwaremaBige und dessen hardwa- 30 
remaBige Realisierungsmoglichkeiten und in mathematischer Notation veranschaulichen. 

Zunachst soil eine softwaremaBige Realisierung in einer C-H-ahnlichen Darstellung beschrieben werden. Im betrach- 
teten Beispiel erfolgt die Verwaltung der Informationen zu den Hardware-Block- Konfigurationsdaten durch Klassen. 

Die Klasse fur eine virtuelle Einheit wird im betrachteten Beispiel folgendermaBen definiert: 

35 
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class clVirtualUnit { 

private: unsigned int uiPhysicalPartNumber ; 
unsigned int uiMneiuonicType; 
BOOL blsConf igurable; 
unsigned int uiConfBits; 
unsigned int uiConf Bitslndex; 
BOOL bTwoSourceRegs; 

unsigned int uiSrcMultiplexN umber [2] ; 

unsigned int uiSrcMultiplexIndex [2] ; 

BOOL bDestinationReg; 

unsigned int uiDestMultiplexNumber; 

unsigned int uiDestMultiplexIndex; 

BOOL blsUsed; 

BOOL bSecondPIsused; 

BOOL blsConstantRegister; 

unsigned int uiConstantlndex; 

unsigned int uiConstantValue; 

public: unsigned int uiGetPartNumber ( void ); 

unsigned int uiGetMnemonicType ( void ); 
BOOL blsUnitConf igurable ( void ); 
unsigned int uiGetConf Bits ( void ); 
unsigned int uiGetConf Bitslndex ( void ); 
BOOL bHasTwoSourceRegs ( void ) ; 
unsigned int uiGetSrcMultiplexNumber 

( unsigned int ) ; 
unsigned int uiGetSrcMultiplexIndex 

( unsigned int ) ; 
BOOL bHasDestinationReg ( void ); 
unsigned int uiGetDestMultiplexNumber ( void ); 
unsigned int uiGetDestMultiplexIndex ( void ); 
void vFreePart ( void ); 
BOOL bMarkUsedPart ( void ) ; 
BOOL bMarkSecondUsedFlag ( void ) ; 
BOOL bGetIsUsed( void ); 
BOOL bGetlsUsedSecondFlag { void ); 
BOOL blsConstantRegister ( void ); 
BOOL bSetConstantValue ( void ) ; 
unsigned int uiGetConstantValue { void ); 
unsigned int uiGetConstantlndex ( void ); 

} 

Die in der Klasse enthaltenen Daten und Methoden dienen zur Modellierung einer Mikroarchitektur. 
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Von den Daten bedeuten: 

uiPhysicalPartNumber: Diese Variable enthalt eine eindeutige Nummer fur die physikalische Teileinheit innerhalb des 
Hardware- Blocks. 

uiMnemonicType: Diese Variable enthalt in codierter Form den Verknupfungstyp, der zu der jeweiligen virtuellen Ein- 
heit gehdrt. 5 
blsConfigurable: Dieses Flag zeigt an, ob die zugehorige physikalische Teileinheit konfiguriert werden muB, um diese 
virtuelle Einheit zu erhalten. 

uiConfBits: Falls blsConfigurable = = TRUE ist, werden hier die zugehorigen Konfigurationsbits gespeichert, um die 
physikalische Teileinheit fur exakt diese Funktion zu konfigurieren. 

uiConfBitsIndex: Falls blsConfigurable = = TRUE ist, wird der Index zur Speicherung der Konfigurationsbits im Bit- 10 
strom an dieser Stelle gespeichert. 

bTwoSourceRegs: Dieses Flag wird auf TRUE gesetzt, falls fur den betreffenden Befehl zwei Sourceregister angegeben 
werden mussen, ansonsten auf FALSE. 

uiSrcMultiplexNumber[2]: Bei zwei Sourceregistern werden die physikalischen Nummem der zugehorigen Multiplexer 

in dieser Variablen gespeichert, gegebenenfalls ist nur die Variable mit dem Index 0 gultig. 15 

uiSrcMultip!exIndex[2]: Hier werden die Indizes der Multiplexer fur die Sourceregister gespeichert. 

bDestinationReg: Dieses Flag wird auf TRUE gesetzt, falls fur den betreffenden Befehl ein Destinationregister (nicht - 

flag!) angegeben werden muB, ansonsten auf FALSE. 

uiDestMultiplexNumber: Hier wird die physikalische Nummer des zugehorigen Multiplexers fur das Zielregister gespei- 
chert. 20 
uiDestMultiplexIndex: Hier wird der Index des Multiplexer fur das Destinationregister gespeichert. 
blsUsed: In diesem Flag wird gespeichert, ob diese virtuelle (und damit zugleich die physikalische) Teileinheit benutzt 
wurde. Ein Setzen dieses Flags auf TRUE bedeutet, daB diese Teileinheit nicht mehr genutzt werden kann (auBer bei den 
bedingten Move-Befehlen (rnovep)). 

bSecondPIsUsed: Fur den Sonderfall der movep-Befehle wird in diesem Flag die zweite Nutzung eines p-Flags ein- 25 
schlieBlich des Vergleichs gespeichert. Sind blsUsed und bSecondPIsUsed auf TRUE gesetzt, ist der dynamische Weg- 
multiplexer (AU), auf den ein movep-Befehl abgebildet wird, zur weiteren Nutzung gesperrt. 

blsConstantRegisten Dieses Flag zeigt an, daB die physikalische Teileinheit einem Konstantenregister entspricht 
(TRUE) oder nicht (FALSE). 

uiConstantlndex: Im Fail cines Konstantenregisters muB der Wert der Konstanten, der gespeichert und genutzt werden 30 
soil, im Bitstrom eingetragen werden. In diesem Fall ist der Index im Bitstrom in dieser Variablen gespeichert. 
uiConstantValue: Der Wert, der im Konstantenregister gespeichert wird, wird fur weitere Vergleiche zusatzlich in dieser 
Variablen der Instanz gespeichert. 

Die in einer Instanz dieser Klasse auftretenden Variablen mussen alle zum Zeitpunkl des Starts der Konfiguration be- 
legt werden. Hicrzu werden hier nicht explizit aufgefuhrte Methoden benutzt, die im Konstruktor einer nachfolgend er- 35 
lauterten Configurable-Block- bzw. CB -Klasse genutzt werden, um alle fur die Umsetzung notwendigen Informationen 
in die Instanz zu schreiben und zugleich die Rags blsUsed und bSecondPIsUsed auf FALSE zu setzen. Wahrend der Le- 
benszeit dieser Instanz andem sich dann nur noch diese beiden Flags, die iiber vordefinierte Methoden mit dem Wert 
TRUE bzw. FALSE belegbar sind, sowie - im Fall eines Konstantenregisters - die Variable uiConstantValue, in der der 
aktuelle Wert des Registers fur weitere Vergleiche zwischengespeichert wird. 40 

Von den Methoden der vorstehend definierten Klasse fur die virtuellen Einheiten bedeuten: 
unsigned int uiGetPartNumber(void): Diese Methode gestattet den lesenden Zugriff auf die Nummer der zur virtuellen 
Teileinheit gehorenden physikalischen Teileinheit; die Nummer wird als Ruckgabewert zuruckgeliefert. 
unsigned int uiGetMnemonicType(void): Diese Methode gestattet den lesenden Zugriff auf Mnemonic, der in der virtu- 
ellen Einheit implementiert werden kann. 45 
BOOL blsUnitConfigurable(void): Diese Methode liefert TRUE, falls die physikalische Teileinheit konfiguriert werden 
muB. Unter diesen Umstanden sind die Eintrage in uiConf-Bits und uiConfBitsIndex gultig und konnen mit den folgen- 
den Methoden uiGetConfBits() und uiGetConfBitsIndex() erhalten werden. Femer mussen alle anderen virtuellen Teil- 
einheiten, die zur gleichen physikalischen Einheit gehoren, ebenfalls gesperrt werden. Fur den Ruckgabewert FALSE 
hingegen sind virtuelle und physikalische Einheit identisch. 50 
unsigned int uiGetConfBits(void): Durch diese Methode werden die Konfigurationsbits gelesen und als Ruckgabewert 
zuruckgeliefert. Diese Werte sind nur gultig, wenn blsConfigurable den Wert TRUE besitzt. 

unsigned int uiGetConfBitsIndex(void): Durch diese Methode wird der Index im Bitstrom fur die Konfigurationsbits ge- 
lesen und als Ruckgabewert zuruckgeliefert. Dieser Wert ist nur gultig, wenn blsConfigurable den Wert TRUE besitzt. 
BOOL bHasTwoSourceRegs(void): Ein Aufruf dieser Methode liefert den Wert TRUE, falls diese Operation zwei Sour- 55 
ceregister besitzt und diese in die entsprechenden Multiplexer einzutragen sind, ansonsten den Wert FALSE, 
unsigned int uiGetSrcMultiplexNumber(unsigned int): Diese Methode liefert die Nummer der physikalischen Teilein- 
heit, die den Multiplexer fur die Sourceregister darstellt, Aufrufparameter ist der Index in dem Array von 2 Eintragen, 
wobei der Index 1 nur giiltige Werte liefert, falls das Flag bHasTwoSourceRegs den Wert TRUE besitzt. 
unsigned int uiGetSrcMultiplexIndcx(unsigned int): Diese Methode liefert den Index zum Eintrag in den Bitstrom, um 60 
die Konfigurierung des Multiplexers fur die Sourceregister vornehmen zu konnen. Aufrufparameter ist der Index in dem 
Array von 2 Eintragen, wobei der Index 1 nur giiltige Werte liefert, falls das Flag bHasTwoSource-Regs den Wert TRUE 
besitzt. 

BOOL bHasDestinationReg(void): Ein Aufruf dieser Methode liefert den Wert TRUE, falls diese Operation ein Destina- 
tionregister besitzt und dies in den entsprechenden Multiplexer einzutragen ist, ansonsten den Wert FALSE. 65 
unsigned int uiGetDestMultiplexNumber(void): Diese Methode liefert die Nummer der physikalischen Teileinheit, die 
den Multiplexer ftir das Destinationregister darstellt. Der Ruckgabewert ist nur gultig, falls das Flag bHas-Destination- 
Reg den Wert TRUE besitzt. 
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unsigned int uiGetDestMultiplex Index (void): Diese Methode liefert den Index zum Eintrag in den Bitstrom, urn die Kon- 
figurierung des Multiplexers fur das Destinationregister vornehmen zu konnen. Der Riickgabewert ist nur gultig, falls das 
Flag bHasDestinationReg den Wert TRUE besitzt. 

void vFreePart(void): Diese Methode loscht alle Belegungsflags, indem diese mit dem Wert FALSE belegt werden. 
5 Hierin erfolgt also ein schreibender Zugriff auf die Rags. 

BOOL bMarkUsedPart(void): Das Belegtflag blsUsed wird iiber diese Methode auf TRUE gcsetzt. Riickgabewert ist 
TRUE, falls die Operation erfolgreich war, FALSE, falls dieses Element bereits belegt war. 

BOOL bMarkSecondUsedFlag(void): Das zweite Belegtflag bSecondPIsUsed wird entsprechend auf TRUE gesetzt. 
Riickgabewert ist auch hier TRUE, falls die Operation erfolgreich war, FALSE, falls dieses Element bereits belegt war. 
10 BOOL bGetlsUsed(void): Diese Methode liefert als Riickgabewert den Wert der Variablen blsUsed. 

BOOL bGetlsUsedSecondFlag(void): Diese Methode liefert als Riickgabewert den Wert der Variablen bSecondPIsUsed. 
BOOL bIsConstantRegister(void): Diese Methode gibt TRUE zuriick, falls die virtuelle Teileinheit einem Konstantenre- 
gister entspricht, ansonsten FALSE. 

BOOL bSetConstantValue(void): Mit Hilfe dieser Methode kann der aktuelle Konstantenwert in der Variablen uiCon- 
15 stantValue gespeichert werden, falls diese virtuelle Einheit einem Konstantenregister entspricht und dieses bisher noch 
nicht belegt wurde. Riickgabewert ist TRUE fur Erfolg, FALSE sonst. 

unsigned int uiGetCons tan tvalue( void): Mit Hilfe dieser Methode wird der gespeicherte Konstantenwert zuriickgegeben. 
unsigned int uiGetConstantlndex(void): Der Index in den Bitstrom, der fur die Speicherung des Konstantenwerts dort 
notwendig ist, wird iiber diese Methode erhalten. 
20 Fur die Modellierung eines Hardware-Blocks (CBs) wird eine zweite Klasse definiert, die u. a. Instanzen der Klasse 
clvirtualUnit sowie weitere Variablen und Methoden enthalt. Zur Vereinfachung wird eine Speicherung der Elemente in 
einem statischen Array angenommen; eine verkettete Liste ist natiirlich ebenfalls denkbar. Es sei an dieser S telle ange- 
merkt, da6 fur die hier angegebenen Klassen nur ein leil der Methoden dargestellt wird. 

25 
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class clCB 
{ 

private: BITFIELD *clbitfield; 

class clVirtualUnit clArrayVirtualUnits 

[NUM OF PARTS] ; 



public: clCB ( ) ; 

void vSetupBitf ield( BITFIELD *) ; 

void vFreeAll ( void ) ; 

BOOL bDoAllPhase_l_Parts 

( unsigned int, BITFIELD * ) 

BOOL bDoCommonPhase_2_Parts ( unsigned int, 

BITFIELD *, 
unsigned int, 
unsigned int, 
unsigned int ) ; 

void vDataForwarding ( unsigned int, unsigned int ); 

void vCopyBitf ield( BITFIELD *, BITFIELD * ); 

unsigned int uiGetMuxCode ( unsigned int, 

unsigned int ) ; 

unsigned int uiGetRegPartNumFromCode 

( unsigned int ) ; 

unsigned int uiGetPartNumFromFlag 

( unsigned int ) ; 

unsigned int uiGetlndexFromNum ( unsigned int ); 

unsigned int uiGetPartNumFromBitf ield 

( unsigned int ) ; 

void vSetBitf ield ( unsigned int, unsigned int, 

unsigned int ) ; } ; 

Die Variablen und Methoden der Klassc clCB bedcuten im einzelnen: 
BITFIELD *clBitfield: Diese Variable entspricht dem zu generierenden Bitstrom fur eine Laufzeitkonfiguration des CB. 
class clVirtualUnit clArrayVirtualUnits[NUM_OF_PARTS]: Dieses Array von Instanzen der Klasse clVirtualUnit ent- 
halt alle Informationen fur alle virtuellen Einheiten und somit auch fur alle physikalischen Teileinheiten. 
clCB(): Dieser Konstruktor wurde aufgefuhrt, um zu verdeutlichen, worin die Aufgaben dieser Klasse bestehen. In einer 
Startphase miissen sowohl das Bitfeld als auch alle Instanzen der Klasse clVirtualUnit, die im Array clArrayVirtualU- 
nits[] zusammengefaBt werden, initialisiert werden. Zur Initialisierung der Klasseninstanzen zahlen insbesondere das 
Beschreiben aller Konfigurationsdaten sowie das Rucksetzen aller Flags, um in der Betriebsphase auf die notwendigen 
Daten lesend zugreifen zu konnen. 

void vSetupBitfield(BITFIELD *): In dieser Methode wird das Bitfeld mil alien Vorbelegungen versorgt. 
void vFreeAll(void): Diese Methode wird zum Loschen aller Belegtflags in dem Array clArrayVirtualUnits aufgerufen. 
BOOL bDoAllPhase_l_Parts(unsigned int, BITFIELD *): In dieser Methode sind alle Teile zur Phase 1 zusammenge- 
faBt. Sie wird aufgerufen, nachdem eine freie Teileinheit zur Aufnahme des Mnemonics gefunden wurde und enthalt die 
Markierung aller zugehbrigen virtuellen Einheiten als besetzt, Bestimmung der Konfigurationsbits und des Index in den 
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Bitstrom und Eintragung in einen temporaren Bitstrom. Parameter sind der Index in dem Array der virtuellen Einheiten 
und der Zeiger auf den temporaren Bitstrom. Der Riickgabewert TRUE zeigt eine erfolgreiche Phase 1 an, FALSE den 
MiBerfolg (etwa durch nicht ausreichende Netzressourcen). 

BOOL bDoCommonPhase_2_JParts(unsigned int, BITFIELD * f unsigned int, unsigned int, unsigned int): Diese Methode 
5 faBt die fur alle Befehlsgruppen gemeinsamen Methoden zusammcn. Hierzu zahlen die Eintrag e fur die Source- und Dc- 
stinationregister einschlieBlich der Behandlung der Konstanten als Eingabcwerte. Ruckgabewert ist TRUE fur Erfolg 
und FALSE fur MiBerfolg. 

void vDataForwarding(unsigned int, unsigned int): Die Berechnung des Data Forwarding mit alien zugehorigen Metho- 
den ist in dieser Methode integriert. Die Vorgehensweise betrifFt die Sourceregister, deren physikalische Nununer in den 
10 Parametem iibergeben werden. Unter Nutzung weiterer Methoden wird ermittelt, ob ein Sourceregister bereits ein friihe- 
res Destinationregister war. Ist dies der Fall, wird die letzte berechnende AU aus dem Bitstrom ermittelt und anstelle des 
Registers eingetragen. 

void vCopyBitfield(BITFIELD *, BITFIELD *): Diese Methode verknupft die Eintragung in dem zweiten Bitstrom mit- 
tels ODER mit denen des ersten und speichert das Ergebnis im ersten Bitstrom. Hierdurch wird das temporare Zwi- 

15 schenergebnis im zur spateren Konfiguration berechneten Bitstrom gespeichert. 

unsigned int uiGetMuxCode(unsigned int, unsigned int): Diese Methode berechnet die Konfigurationsbits, die fur einen 
Multiplexer in den Bitstrom zu laden sind, um als Quelle eine physikalische Teileinheit auszuwahlen. Parameter dieser 
Methode sind die physikalische Nummer des Multiplexers sowie der Quelleinheit. Diese Methode ist unbedingt notwen- 
dig zur Konfiguration, da in der Beschreibung der virtuellen Einheiten zwar der Index des Eintrags, nicht jedoch der Ein- 

20 trag selbst gespeichert wird. Diese Methode kann fiir ein vollstandiges Nctzwerk als tabellengestiitzte Umrechnung ge- 
gebenenfalls ohne Beriicksichtigung der Multiplexernummer implementiert sein, da in diesem Fall alle Multiplexer auf 
einheitliche Weise konfigurierbar sind. Fur partielle Netzwerke muB hier grbBerer Aufwand betrieben werden, insbeson- 
dere kann eine Vernetzung unmoglich sein. Ruckgabewert sind die Konfigurationsbits im Erfolgsfall bzw. eine sonst un- 
genutzte Codierung fiir den Fall des MiBerfolgs. 

25 unsigned int uiGetRegPartNumFromCode(unsigned int): Diese Methode berechnet die Nummer der Teileinheit aus dem 
Code in der Instruktion. Dies kann naturgemaB nur fiir Register erfolgen, wobei im Fall einer Konstanten die beschrie- 
bene Vorgehensweise in dieser Methode integriert ist, die zur Speicherung der Konstanten und zur Ruckgabe der physi- 
kalischen Nummer des Konstantenregisters fiihrt. Ruckgabewerte sind die Nummer der Teileinheit im Erfolgsfall, an- 
sonsten eine nicht benutzte Kennung fur den MiBerfolg. 

30 unsigned int uiGetPartNumFromFlag(unsigned int): Fiir die Umrechnung einer Hagnummer in die Nummer der physi- 
kalischen Teileinheit ist diese Methode zustandig. Aufrufparameter ist das p-Feld in dem Instruktionsformat, Riickgabe- 
wert die Teileinheitsnummer oder eine besondere Kennung im Fall des MiBerfolgs. 

unsigned int uiGetIndexFromNum(unsigned int): Mit Hilfe dieser Methode wird der Index in den Bitstrom fur eine Teil- 
einheit mit bekannter physikalischer Nummer (als Parameter) berechnet und zuruckgegeben. Diese Berechnung kann in 
35 Tabellenform erfolgen. 

unsigned int uiGetPartNumFremBilfield(unsigned int): Diese Methode liest den Eintrag in dem Bitfeld an dem als Para- 
meter ubergebenen Index und rechnet die erhaltene Konfigurationsmaske in die physikalische Nummer der Teileinheit 
zuriick, die als Ergebnis zuruckgegeben wird. uiGetPartNumFrornBitfield wird im Data Forwarding eingesetzt, wo der 
Datenweg von einem fruheren Zielregister auf die das Ergebnis bestimmende Teileinheit zuriickverfolgt wird, damit die 
40 Daten vorzeitig verwendbar sind. 

void vSetBitfield(unsigned int, unsigned int, unsigned int): Diese Methode wird mit drei Parametern aufgerufen: Der In- 
dex der Eintrags, die Lange des Eintrags und die Maske. Der Aufruf bewirkt den Eintrag in dem Bitfeld an der entspre- 
chenden Steile. 

Mit den vorstehend genannten und erlauterten Variablen und Methoden ergibt sich folgender Pseudocode fiir das Ver- 
45 fahren zur der auf Befehlen oder Befehlsfolgen basierenden Konfigurierung eines Hardware-Blocks der in der Fig. 12 
dargestellten Art (fur die struktur-prozedurale Programmierung): 
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unsigned int k; 

BITFIELD +clTempBitfield; 

// 1. Phase: Bestimmung einer physikalischen Teileinheit zur 
// Aufnahme der Verkniipfung. 
// mnenomic in uiMem stehend 

vSetupBitfield( clTempBitf ield ); 

for( k = 0; k < NUM_OF_PARTS; k++ ) 
{ 

if( clArrayVirtualUnits [k] : : uiGetMnenomic { ) == uiMem 

&& clArrayVitualOnit [k] : : bGetlsUsed ( ) == FALSE ) 
break; 

} 

if ( k == NUM_OF_PARTS ) // Keine freie Verkniipfung gefunden 
return ( FALSE ) ; 

// Jetzt wird die freie Teileinheit als besetzt markiert, 
// gegebenenf alls eine Konf igurierung bestimmt und in diesem 
// Fall auch alle anderen virtuellen Einheiten als besetzt 
// markiert. Alle Maskenbits werden in einem temporaren 
// Bitstrom gespeichert. 

if( bDoAllPhase_l_Parts ( k, clTempBitf ield ) === FALSE ) 
return ( FALSE ) ; 

// Nunmehr beginnt die zweite Phase: Fur alle Instruktionen 
// werden die beiden, gegebenenf alls ein Sourceregister 
// bestimmt und in den Bitstrom eingetragen. Entsprechendes 
// erfolgt mit dem Destinationregister, falls vorhanden. Die 
// entsprechenden Codierungen aus der Instruktion stehen in 
// den Variablen uiSourceRegl, uiSourceReg2 und uiDestReg, 
// wobei gegebenenf alls Konstanten als Quellen hier erkennbar 
// sind. 
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if( bDoPhase_2_CommonParts ( k, clTempBitf ield uiSourceRegl, 
uiSourceReg2, uiDestReg == FALSE ) 
5 return ( FALSE ) ; 

switch { uiMnemonicType ) 
to I 

case BEDINGTER_BEFEHL // p-Flag bestimmen, Eintrag fOr CU 
case MOVEP_BEFEHL: // spez. erster Eintrag, 

i5 // zweiter Eintrag moglich 

} 

vDoDataForwarding ( uiSourceRegl, uiSourceReg2 ); 

20 

// Die letzte Aktion: Der temporar gespeicherte Bitstromcode 
// wird in den eigentlichen Bitstrom kopiert 

25 

vCopyBitf ield ( clBitfield, clTempBitf ield ); 
return ( TRUE ) ; 

30 

Die vorstehende zentrale Routine wird fur jede Instruktion, die iibersetzbar ist, aufgerufen. Riickgabewert ist TRUE, 
falls die Umsetzung gelungen ist, ansonsten FALSE. Im letzteren Fall muB die Instruktion im aufrufenden Programm be- 
halten werden, da sie nicht eingefiigt wurde, und der Bitstrom kann zur Ausfuhrung geladen werden. Das Ende einer Um- 
setzung wird also durch das Erschopfen der Ressourcen angezeigt oder durch eine nicht-iibersetzbare Instruktion wie 

35 beispielsweise einen Branchbefehl erhalten. 

Wie vorstehend bereits erwahnt wurde, laBt sich die strukturprozedurale Programmierung nicht nur softwaremaBig, 
sondern auch hardwaremaBig realisieren. Eine mogliche Ausfiihrungsform einer hardwaremaBigen Realisierung wird 
nachfolgend unter Bezugnahme auf die Fig. 2 bis 10 erlautert. Dabei wurde ver-sucht, die einzelnen Phasen so weit wie 
moglich parallel durchlaufen zu lassen. 

40 Die bei der softwaremaBigen Realisierung vorkommenden tabellengestiitzten Umrechnungen werden bei der hardwa- 
remaBigen Realisierung als sogenannte Look-Up-Tables (LUTs) realisiert. LUTs sind dazu ausgelegt, im Ansprechen auf 
die Eingabe von Daten von diesen abhangende Daten auszugeben, Solche LUTs konnen beispielsweise durch ein 
EPROM oder eine andere Speichereinrichtung gebildet werden. Die eingegebenen Daten werden dann als Adresse ver- 
wendet, und die ausgegebenen Daten sind die unter dieser Adresse gespeicherten Daten. 

45 Fur die erste Phase wird eine LUT der in der Fig. 2 veranschaulichten Art verwendet. Diese LUT weist zwei Eingange 
(Address, Counter_Address) und vier Ausgange (Code, Complementary, Counter_Up, No_Entry) auf. Die zwei Ein- 
gange dienen der Adressierung der LUT, wobei die uber den einen Eingang (Address) zugefuhrten Daten und/oder Si- 
gnale vom zu ubersetzenden Code abhangen, und wobei die uber den anderen Eingang (Counter_Address) zugefuhrten 
Daten und/oder Signale Zahlstande eines durch den Ausgang Counter_Up hochzahlbaren Zahlers (Zahler-Arrays) sind. 

50 Die Ausgange dienen zur Ausgabe des ubersetzten Codes (Code), von Signalen zum Hochzahlen des die Counter_Ad- 
dress generierenden Zahlers oder Zahler-Arrays (Counter_Up), eines Signals zur Signalisierung fiir den Fall, daB kein 
giiltiger und freier Eintrag mehr vorliegt (No_Entry), und eines fur die Bearbeitung bedingter Move-Befehle (movep) be- 
notigten Signals (Complementary), wobei sich der ubersetzte Code aus Konfigurations-Bits (Config-Bits), einem Konfi- 
gurationsindex (Con fig -Index), und einer Teilenummer (Part-Number) zusamniensetzt. Die Look-Up-Table- Eintrage ha- 

55 ben damit fur den erstcn Teil das in Fig. 3A gezeigte Format. 

Der erwahnte Zahler (das Zahler- Array) wird als Markierungsmittel (besetzt, schreibend) verwendet, wobei fiir jeden 
Operations-TVpen (Addition, Subtraktion . . .) ein separater Zahler existiert. Der Zahlstand der Zahler gibt an, die wie- 
vielte Moglichkeit zur Ausfuhrung des zugeordneten Operations-TVps in Anspruch genommen werden kann. Die Tiefe 
der Zahler innerhalb dieses Zahler-Arrays hangt von der Anzahl der Moglichkeiten zur Ausfuhrung der betreffenden 

60 Operation ab. Sind beispielsweise drei Additionsmoglichkeiten vorhanden, betragt die Zahlertiefe zwei Bit; in der kor- 
respondierenden LUT, die ja von dem Mnemonic-Code und dem Zahlerstand adressiert wird, wird dann allerdings an der 
4. Stelle (Zahlerstand 3) eine NO_ENTRY-Codierung stehen, um das Fehlen dieser Operation anzuzeigen; ein derartiger 
LUT-Eintrag ist in Fig. 3B veranschaulicht. 

Die besagten Zahler sind im betrachteten Beispiel Binarzahler mit asynchronem Reset und Enable. Ein 2-Bit-Binar- 

65 zahler dieser Art ist im betrachteten Beispiel wie folgt codiert; die Darstellung erfolgt in dem bei DNF(Disjunktive Nor- 
mal-Form)-Logiken gebrauchlichen DNF-Format. Zahler dieser Art werden im folgenden als Zahler eines ersten Typs 
bezeichnet. 
BIT bO,bl:OUT; 
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BIT reset, enable:IN; 
BITclockrIN; 

bO = /bO * enable + bO * /enable; 
bO.clk = clock; 

bO.arcset = reset; 5 
bl = /bl * bO * enable + bl * /bO * enable + bl * /enable; 
bl.clk = clock; 
b 1 .areset - reset; 

Parallel zu diesen Zahlem muB fur die bedingten Befehle ein Speicherarray implementiert sein, um den Code des Be- 
dingungsflags speichern zu konnen. Dies ist, wie vorstehend bereits erlautert wurde, zur Zusammensetzung von Movep- to 
Befehlen notwendig. Da es nur eine CU-Instanz pro Flag geben kann (im Gegensatz zu den AUs gibt es zwar irn allge- 
meinen mehrere Flags, die sich jedoch alle durch die Bezeichnung des Bits unterscheiden), besteht der Binarzahler aus 
zwei Bits, von denen das erste die Erstbelegung, und das zweite die Komplementarbelegung anzeigt. Die Identifizierung 
der korrekten CU erfolgt anhand der p-Bits aus dem Befehl. 

Die 2-Bit-Binarzahler fur bedingte Move-Befehle sind im betrachteten Beispiel wie folgt codiert; die Darstellung er- L5 
folgt wiederum in dem bei DNF(Disjunktive Normal-Form)-Logiken gebrauchlichen DNF-Format. Zahler dieser Art 
werden im folgenden als Zahler eines zweiten Typs bezeichnet. 
BITb0,bl:OUT; 
BIT reset, enablerIN; 

BITclockrIN; 20 

b0 = /b0* enable + bO; 

bO.clk = clock; 

bO. areset = reset; 

bl=/bl *b0* enable + bl; 

bl.clk = clock; 25 
b 1 .areset = reset; 

Fur die Falle, in denen Entscheidungen getroffen werden miissen, die in Datenpfade umgesetzt werden, wird eine spe- 
zielle Logik integriert. 

Fur die 1. Phase des Verfahrens zur Hardware-Block-Strukturierung ergibt sich nach alledem die in Fig. 4 gezeigte 
Realisierung. 30 

Fiir alle Befehle mit Ausnahme der bedingten Movep-Instruktionen wird pro arithmetischer Einheit AU bzw. pro Ver- 
gleichs-Einheit CU eine Zahlerinstanz nach Art des vorstehend erlauterten Zahlers des ersten typs benotigt. Ein solcher 
Zahler geniigt, da nur ein einfaches Belegt-Signal benotigt wird. Die Movep-Anweisungen hingegen benotigen einen 
Zahler des zweiten Typs, der in zwei Bits die teilweise (bO) und die vollstandige (bl) Belegung signalisiert. Bedingte 
Movep-Instruktionen, die zum zweiten Mai auf das gleiche Flag referenzieren, miissen dieses in (im Vergleich zur ersten 35 
Referenz) invertierter Form vornehmen und werden dann in der entsprechenden AU als zweite Quelle eingetragen, wah- 
rend das erste Quellregister unverandert bleibt. Dieses Verfahren ist in einer LUT integrierbar; Referenzen auf die nicht 
invertierten Bedingungen werden durch eine No_Entry-Signalisierung abgebrochen. 

Die zweite Phase umfaBt die Bestimmung der Register, die fur die betreffende Operation als Daten- und/oder Signal- 
quelle(n) und Daten- und/oder Signalziel zu verwenden sind. Dies erfolgt fur alle drei moglichen Register in paralleler 40 
und weitgehend identischer Form. Die Codierung des jeweiligen Registers innerhalb der Instruktion wird - falls das be- 
treffende Feld einen gultigen Eintrag enthalt - durch eine Look-Up- Table in eine Maske fur den Bitstrom zusammen mit 
dem Index in den Bitstrom umgesetzt. 

Das Blockschaltbild einer Schaitung zur Bestimmung und Codierung der als Daten- und/oder Signalquelle(n) und Da- 
ten- und/oder Signalziel zu verwendenden Register ist in Fig. 5 veranschaulicht; die Identifizierung, welche der Register 45 
tatsachlich umgesetzt werden (miissen), erfolgt im betrachteten Beispiel durch die Steuerleitungen Source_Reg_l, Sour- 
ce_Reg_2, und Dest_Reg (siehe Fig. 4 und 5). 

Source- und Destinationregister werden unterschiedlich behandelt. Im Fall eines Destinationregisters wird der Eintrag 
markiert, um eine Zweitbelegung identifizieren zu konnen (Signal No_Entry) und um ein Data Forwarding zu triggern. 
Diese Signale entfallen fur Sourceregister. Hier wird eine "straight-forward M -Generierung des Bitstromeintrags durchge- 50 
fuhrt, wobei allerdings die Generierung des Codes im Fall einer Konstanten entfallt und auf die nachfolgend beschrie- 
bene Stufe verlagert wird. 

In der Fig. 5 ist markiert, was ausschlieBlich fur Sourceregister und ausschlieBlich fur Destinationregister relevant ist: 
mit (*) gekennzeichnete Teile sind nur fur Destinationregister bestimmt, und mit (**) gekennzeichnete Teile sind nur fiir 
Sourceregister bestimmt. 55 

Fiir eine Konstante, die innerhalb der Codierung anstelle eines Sourceregisters auftreten kann, wird ein paralleler Weg 
durchgefuhrt, der die Konstante mit den Inhalten aller Konstantenregister parallel zueinander vergleicht, und - bei Un- 
gleichheit - das nachstfreie Register (Zeigerverwaltung durch einen Zahler) mit der Konstanten belegt und dieses Regi- 
ster als Codierung zuruckliefert oder - bei Gleichheit - die Codierung des die Konstante enthaltenden Konstantenregi- 
sters als Codierung zuruckliefert. 60 

Die Look- Up-Table wird zu diesem Zweck so gestaltet, daB sie bei einem positiven Vergleich unmittelbar die Codie- 
rungsnummer des betreffenden Registers zum Bitfeld liefert, wahrend im Fall einer Nichtiibereinstimmung zusatzlich 
die Konstante gespeichert und der Registerzahler erhoht wird. Das No_Entry-Signal wird fiir den Fall einer Belegung al- 
ler Konstanten aktiv und beendet den Algorithmus fur einen Ins truktionsb lock, da die Ressourcen erschopft sind. Es 
sollte zudem beachtet werden, daB die Konstantenregsiter ein Teil des (Main-)Bitstroms sind, da sie aus vorhergehenden 65 
Zyklen bereits belegt sein konnen und zum Laden des Instruktionsblocks benotigt werden. 

Das Blockschaltbild einer Schaltung zur Zuordnung der Konstantenregister ist in Fig. 6 veranschaulicht. 
Fiir Sourceregister wird das bereits mehrfach erwahnte Data Forwarding durchgefuhrt. Anhand der Eintragung in das 
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Belegtflag des Registers, die anzeigt, daB dieses Register in diesem Zykius bereits Zielregister war, wird entschieden, ob 
tatsachlich das Sourceregister oder die Eintragung, die als Quelle fur das Zielregister ermittelbar ist, als neue Quelle in 
den Bitstrom eingetragen wird. 

Das Blockschaltbild einer hierzu geeigneten Schaltung ist in Fig. 7 dargestellt. 
5 Die im Fig. 7 per LUT durchgefuhrte Umcodierung der neuen Quelle kann entfallen, falls alle Quellen innerhalb des 
Netzwerks identisch codiert werden. Dieser Fall, der fur ein vollstandiges Netzwerk angenommen werden kann, fuhrt 
dazu, daB die im temporaren Bitstrom stehende Eintragung der Quelle fur das (fruhere) Zielregister als neue Quell-Co- 
dierung fur die jetzige Operation anstelle des in der Instruktion codierten Quellregisters eingetragen wird. Die Auswahl 
erfolgt in jedem Fall durch einen iiber das Signal Is_Data-Forwarding (sieheFig. 5) angesteuerten Multiplexer, 
to Fiihren alle Operationen zum Erfolg (dies ist anhand des Auftretens keiner No_Entry-Signalisierung erkennbar), wird 
der temporare Bitstrom beim Schreibtakt mit dem vorhandenen Hauptbitstrom ODER-verkniipft und in diesen zuriick- 
geschrieben. 

Die Fig. 8 und 9 zeigen Blockschaltbilder zum Einschreiben von Konfigurationsdaten in den temporaren Bitstrom und 
in den Hauptbitstrom (main bitstream). 
15 Wie aus der Fig. 8 ersichtlich ist, erfolgt das Einschreiben von Konfigurationsdaten in den temporaren Bitstrom iiber 
sogenannte Cross-Bar- Switches. Cross-Bar- Switches sind allgemein bekannt und bediirfen keiner naheren Erlauterung. 
Sie leiten die Konflgurationsbits (Config-Bits) an die durch den Config-Index definierten Stellen im temporaren Bit- 
strom, wobei unbelegte Ausgange des Cross- Bar- Switch mit einem vorbestimmten Wert (beispielsweise "0") belegt sind. 
Fur die mnemonic-basierte Auswahl einer physikalischen Teileinheit, die Konfiguration derselben und die Zuordnung 
20 der Source- und Destinationregister zu dieser ist jeweils ein eigener Cross-Bar-Switch gemaB Fig. 8 notwendig. 

Die Umsetzung des temporaren Bitstroms in den Hauptbitstrom (die Uberlagerung des Hauptbitstroms durch die Aus- 
gange der Cross-Bar- Switches erfolgt durch ODER-Gatter OR am Eingang des Hauptbitstroms (siehe Fig. 9)). 

Die vorstehend beschriebenen Komponenten lassen sich wie in Fig. 10 gezeigt zu einer Anordnung zusammenfugen, 
die in der Lage ist, aus m-bits, ksl-Bits, ks2-Bits, kd-Bits und p-Bits zusammengesetzte Befehle (sieheFig. 1A bis ID) in 
25 Konfigurations-Daten zur Konflgurierung eines Hardware-Blocks umzusetzen und diese Daten in einen zur Konfigurie- 
rung des Hardware-Blocks verwendbaren Bitstrom einzuschreiben. 

AbschlieBend wird die angestrebte Umsetzung (die struktur-prozedurale Programmierung) auch noch in mathemati- 
scher Notation angegeben. 

Hierzu muB zunachst eine Reihe von die Darstellungen und die Abbildungen betreffenden Vereinbarungen getroffen 
30 werden. Es seien 

I + die Menge aller Instruktionen 

I die Menge aller DatenfluB-relevanten (fur die Blockausfuhrung geeigneten) Instruktionen 

SR die Menge aller Sourceregister einschlieBlich NO-SOURCE-Darstellung, ausschlieBlich der Konstantenregister 
CR die Menge aller Konstantenregister einschlieBlich der Darstellungen fur NO_CONST und IS_CONST 
35 SR + SR U CR 

DR die Menge aller Destinationregister einschlieBlich NO_DEST-Darstellung ausschlieBlich der Predicate-Bits 
PR die Menge aller Predicate-Bits einschlieBlich NO_PRED 
DR + DR U PR 

RN die Menge aller Register, SR U CR U DR 
40 RN + die Menge aller Register einschlieBlich Predicate Bits, RN U PR 

List(pp) die Menge aller moglichen Werte fur den Bitstrom B als 4-Tupel (px e PP, offset < k, nbit < k, bitwert < 2 k - 1), 
gegebenenfalls abhangig von pp e PP 

Nbit die Menge der moglichen Bitwerte (bei n Bit Datenbreite: 0 ... 2 n - 1) 
B die Menge von k binarwertigen Eintragen als der Bitstrom zur Konfiguration der Struktur 
45 OCC die Menge aller Belegungsrnarkierungen {FREE, WRITE, READ, READ WRITE } 
PP die Menge aller physikalischen Teileinheiten 

PLNUM die Menge aller eindeutigen Nummem fur die logischen Einheiten 

PL die Menge aller logischen Teileinheiten in einem CB, bestehend aus dem 11 -Tupel (pi e I U RN% plnum e 
PLNUM, pp e PP, occ e OCC, source <E PLNUM, val <E Nbit, pbit e PR, List(pp), konfDffset < k, konfAnzahl < k, 
50 konfWert<2 k - 1) 

Bei der folgenden Beschreibung werden einige Grundannahmen und Funktionen genutzt, die zunachst erlautert wer- 
den sollen. Die Kennung innerhalb der Komponente occ (fur occurence) wurde vierwertig gewahlt, um die Zustande 
'nicht belegt' (FREE), 'lesend belegt' (READ), 'schreibend belegf (WRITE) und 'lesend und schreibend belegt' (RE- 
AD_WRITE) kennzeichnen zu konnen. Die Kennung lesend belegt' wird dabei gegebenenfalls nicht weiter ausgewertet, 
55 aber dennoch innerhalb der Beschreibung weitergefuhrt. 

Weiterhin wird fur die Register aus RN angenommen, daB fur diese Teileinheiten die logische und physikalische Dar- 
stellung ubereinstimmt. Dies bedeutet, daB im Gegensatz zu mancher funktionalen Teileinheit (etwa eine konfigurierbare 
Addition/Subtraktionseinheit die als zwei logische Einheiten dargestellt wird, aber naturlich nur einmal belegbar ist) fiir 
Register keine Konflgurierung durchzufiihren ist, und daB zwischen der Regi stern uinmer rn e RN und der logischen 
60 Teileinheitsnununer plnum e PLNUM eine injektive Abbildung (gleichwohl nicht bijektiv) existiert, die im folgenden 
mit m2plnum() bezeichnet wird. Diese Annahme gilt nicht fiir Predicate-Bits als Zielbits. 

Unter diesen Voraussetzungen laBt sich die Umsetzung von Befehlen in Strukturinformationen zur Strukturierung von 
Hardware-Blocken wie folgt umschreiben: 

65 1. In der ersten Phase wird jede Instruktion einschlieBlich aller Operanden aus dem originalen Binarformat in eine 

Beschreibung bi = (i e I, srl e SR, crl e CR, nl e Nbit, sr2 <= SR, cr2 e CR, n2 e Nbit, dr e DR, pr_source e 
PR, pr_dest e PR) ubergefuhrt. In dieser Beschreibung wird fur eine Konstante die Kennung IS_CONST fur crl 
bzw. cr2 sowie der Konstantenwert in nl/n2 eingetragen, wobei in diesem Fall das entsprechende Sourceregister die 
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Kennung NO_SOURCE erhalt. Entsprechend wird fur Predicate-Befehle (etwa pge . . .) fur dr NO_DEST einge- 
setzt, wahrend pr_dest dann die Nummer des Predicate-Bits tragt. 

Fur Predicated Instructions (etwa movep) wird zur besseren Unterscheidbarkeit nicht pr_dest, sondern pr_source 
auf einen entsprechenden Wert gesetzt, 

Eine Instruktion mit j £ I bewirkt ein Beenden der Umsetzung. 5 

2. In der zweiten Phase werden maximal funf Eintrage in bi in eine Konfiguration ubersctzt. Fiinf deshalb, die sich 
einige Kombinationen gegenseitig ausschlieBen. Hirerzu wird fur die einzelnen Teile unterschieden: 

Fur Instruktionen bi — e I und bi— ►pr.dest = = NO_PRED (keine Predicate- Anweisung) wird das erste Element pi 
E. PL gesucht, das dieses i abdeckt und occ = = FREE aufweist. 1st dies nicht auffindbar, so wird die Umsetzung be- 
endet, 10 
1st pi gefunden, so werden alle Elemente aus PL mit occ = = READ_WRITE belegt, die auf das selbe physikalische 
Element, pp e PP abgebildet sind. Die Konfiguration fur pi wird in den Bitstrom B mit Hilfe der im Tupel vorhan- 
denen Informationen eingetragen. 

1st bi— pr_source = = NO_PRED, so wird hierfur keine Eintragung durchgefiihrt. Ansonsten wird nach einem p2 e 
PL mit p2— >-pbit = = bi— >-pr_source gesucht, wobei p2^-K)cc = = WRITE sein muB. Fur dieses p2 wird via 15 
List(p2— pp) pi gesucht und die Eintragung in den Bitstrom vorgenommen, auBerdem wird p2— *occ auf RE- 
AD_WRITE gesetzt. 

Fiir Instruktionen bi— *i e I und bi— ►pr^dest != NO_PRED (Predicate- Anweisung) wird das erste Element pi e PL 
gesucht, das dieses i abdeckt und occ = = FREE aufweist. 1st dies nicht auffindbar, so wird die Umsetzung beendet. 
1st pi gefunden, so werden alle Elemente aus PL mit occ = WRITE belegt, die auf das selbe physikalische Element 20 
pp e PP abgebildet sind. Die Konfiguration fiir pi wird in den Bitstrom B mit Hilfe der im Tupel vorhandenen In- 
formationen eingetragen. 

Fur alle Instruktionen i e I gilt: Fiir bi— srl und bi— *sr2, fur die != NO_SOURCE gilt, wird durch List(pl— ►pp) die 
entsprechende Konfiguration in den Bitstrom B eingesetzt, falls fur die zu srl/2 gehorigen pi 1/1 2 e PL, p 11— occ 
= = FREE, und pl2— K)cc = = FREE gilt, zudem wird pi— ►plnum bei pll/12-source eingetragen (fur spateres For- 25 
warding). 1st dies nicht der Fall, wird Phase 3 (Data Forwarding) durchgefiihrt. 

Fiir die Sourceregister bi— srl und bi— »sr2 wird, falls diese != NO_SOURCE sind, in PL die entsprechenden Ein- 
trage fur die zugehorigen p31 und p32 e PL (erhaltlich uber die angegebene Funktion rn2plnum()) p31— occ und 
p32— occ auf READ gesetzt, falls diese vorher != WRITE und != READ_WRITE waren, ansonsten auf RE- 
AD_WRITE. 30 
Fiir die Konstantenregister crl und cr2 wird, falls diese != NO_CONST sind, zunachst fur alle p3 e PL gepriift, ob 
p3— ►pp e CR, p3 — kxjc = = READJWRITE, und p3— ►val = = bi— nl/2 gilt. 1st dies der Fall, wird die Eintragung 
fur p3 entsprechend dem Verfahren fur ein Sourceregister durchgefiihrt. 

Fuhrt diese Suche nicht zum Erfolg, muB ein p3 e PL gesucht werden, fiir das p4— ►pp e CR und p4— occ = = 
FREE gilt. 1st dies gefunden, wird bi— nl/2 in p4 — ►val eingetragen und p4 — mdcc = READ_WRJTE gesetzt sowie 35 
die Eintragung wie bei einem Sourceregister fortgefuhrt. 1st die Suche erfolglos, wird die Umsetzung beendet. 
Fiir das Destinationregister dr wird gepriift, ob fiir den entsprechenden Eintrag p5 mit p5— pp = = dr die Bedingung 
p5— occ = = FREE oder READ gilt. 1st dies nicht dar Fall, wird die Umsetzung beendet, ansonsten wird p5— occ = 
WRITE oder READ_WRITE gesetzt und die Eintragung in List(p5— pp) wird in den Bitstrom B iibertragen. Fur ein 
eventuelles Data Forwarding wird p5— source = pi (logisches Element der wertgebenden Instruktion) eingetragen. 40 

3. Fiir alle Sourceregister sr e SR, die in Phase 2 den Wert fur das zugehorige Element p6 e PL den Wert p6— occ 
= = WRITE oder READ_WRITE aufweisen, wird ein Data Forwarding durchgefiihrt, indem in den Bitstrom B 
nicht die Werte aus List(p6), sondern aus List(p6— source) eingetragen werden. 

Die vorstehenden Darstellungen und Realisierungsmoglichkeiten bezogen sich jeweils auf einen Hardware-Block der 45 
in der Fig. 12 gezeigten Art. Es diirfte einleuchten, daB hierauf keine Einschrankung besteht. Die beschriebene Umset- 
zung von Befehlen oder Befehlsfolgen in Hardware-Block-Strukturen laBt sich dem Wesen nach auch bei modifizierten 
oder erweiterten Hardware-Blocken realisieren. Sie ermoglicht es unabhangig hiervon, konfigurierbare Hardware- 
Blocke automatisch zu konfigurieren, wobei die Konfiguration sehr schnell durchfiihrbar ist, die Komponenten des Hard- 
ware-Blocks optimal ausnutzbar sind, und einen auBerst efFektiven Betrieb des Hardware-Blocks ermoglicht. 50 

Bezugszeichenliste 

1 predecode unit 

2 instruction buffer 55 

3 decode, rename & load unit 

4 s-unit 

5 data cache 

6 memory interface 

41 programmable structure buffer 60 

42 functional unit with programmable structure 

43 integer/address instruction buffer 

44 integer register file 
AUx arithmetische Einheit 

CU Vergleichs-Einheit 65 

DEMUX Demultiplexer 

MUXAx Multiplexer des ersten TVps 

MUXB Multiplexer des zweiten Typs 
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Patentanspriiche 

1. Verfahren zum Konfigurieren eines konfigurierbaren Hardware-Blocks, so daB dieser durch Befehle oder Be- 
fehlsfolgen vorgegebene arithmetische und/oder logische Operationen oder Operationsfolgen ausfuhren kann, da- 

5 durch gekennzeichnet, 

daB fur die Umsetzung der abzuarbeitenden Befehle in eine Hardware-Block-Struktur die Schritte 

- Ermittlung der zur Ausfuhrung eines jeweiligen Befehls benotigten Art von Teileinheit (AUx, CU, DE- 
MUX, MUXAx, MUXB) des konfigurierbaren Hardware-Blocks, 

- Auswahl einer noch nicht anderweitig belegten Teileinheit der zuvor errnittelten Art, und - sofern eine sol- 
10 che Teileinheit gefunden werden konnte - 

- Konfigurieren von um die ausgewahlte Teileinheit herum vorgesehenen konfigurierbaren Verbindungen 
ausgefuhrt werden. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daB die Umsetzung mit dem ersten Befehl eines nur einen 
Eintrittspunkt und einen Auslrittspunkt aufweisenden Befehls-Blocks begonnen wird. 

15 3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB die Umsetzung nach dem Umsetzen des letzten 

Befehls eines nur einen Eintrittspunkt und einen Austrittspunkt aufweisenden Befehls-Blocks automatisch beendet 
wird. 

4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, daB die Umsetzung hyperblock-weise erfolgt. 

5. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Umsetzung automatisch 
20 beendet wird, wenn eine zur Umsetzung benotigtc Komponcnte des Hardware- Blocks nicht oder nicht mehr verfug- 

bar ist. 

6. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB funktionsmaBig konfigu- 
rierbaren Teileinheiten (AUx, CU, DEMUX, MUXAx, MUXB) des Hardware-Blocks virtuelle Einheiten zugeord- 
net werden, wobei die virtuellen Einheiten Funktionen reprasentieren, welche der betreffenden Teileinheit durch un- 

25 terschiedliche Konfigurationen verliehen werden konnen. 

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daB die virtuellen Einheiten samtlicher physikalischer 
Teileinheiten (AUx, CU, DEMUX, MUXAx, MUXB) in einer Tabelle oder Liste eingetragen sind. 

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daB die Tabellen- oder Listeneintrage Informationen dar- 
uber enlhalten, welcher physi kali sc hen Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) die betreffende virtuelle 

30 Einheit zugeordnet ist. 

9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, daB die Tabellen- oder Listeneintrage Informatio- 
nen daruber enthalten, wie die zugeordnete physikalischen Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) zu 
konfigurieren ist, um ihr die durch die virtuelle Einheit reprasentierte Funktion zu verleihen. 

10. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Auswahl einer zur 
35 Ausfuhrung eines Befehls benotigten Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) iiber eine Suche nach ei- 
ner virtuellen Einheit der benotigten Art erfolgt. 

11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daB daftir gesorgt wird, daB die zur Verwendung ausge- 
wahlte virtuelle Einheit der benotigten Art und diejenigen virtuellen Einheiten, die der selben physikalischen Teil- 
einheit (AUx, CU, DEMUX, MUXAx, MUXB) zugeordnet sind wie die ausgewahlte virtuelle Einheit, bei nachfol- 

40 genden Umsetzungen nicht mehr zur Verwendung ausgewahlt werden konnen. 

12. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB beim Konfigurieren der 
umdie ausgewahlte Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) herum vorgesehenen konfigurierbaren Ver- 
bindungen zur Verbindung der betreffenden Teileinheit mit einer durch den umzusetzenden Befehl definierten Da- 
ten- und/oder Signalquelle uberpriift wird, ob die betreffende Daten- und/oder Signalquelle ein Speicherbereich ist, 

45 der zuvor durch eine der Teileinheiten des Hardware-Blocks beschrieben wurde. 

13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, daB dann, wenn festgestellt wird, daB die durch den um- 
zusetzenden Befehl definierte Daten- und/oder Signalquelle zuvor durch eine der Teileinheiten (AUx, CU, DE- 
MUX, MUXAx, MUXB) des Hardware-Blocks beschrieben wurde, diese Teileinheit als Daten- und/oder Signal- 
quelle verwendet wird. 

50 14. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB beim Konfigurieren der 

um die ausgewahlte Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) herum vorgesehenen konfigurierbaren Ver- 
bindungen zur Verbindung der betreffenden Teileinheit mit einem durch den umzusetzenden Befehl definierten Da- 
ten- und/oder Signalziel iiberpruft wird, ob das betreffende Daten- und/oder Signalziel ein Speicherbereich ist, der 
auch durch eine andere Teileinheit des Hard ware- Blocks beschrieben wird. 

55 15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daB dann, wenn festgestellt wird, daB das durch den um- 

zusetzenden Befehl definierte Daten- und/oder Signalziel ein Speicherbereich ist, der auch durch eine andere Teil- 
einheit (AUx, CU, DEMUX, MUXAx, MUXB) des Hardware-Blocks beschrieben wird, ein anderer Speicherbe- 
reich als Daten- und/oder Signalziel verwendet wird. 

16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, daB fur die das selbe Daten- und/oder Signalziel reprii- 
60 sentierenden Speicherbereiche das bei superskalaren Prozessoren angewandte register renaming durchgefuhrt wird. 

17. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB dann, wenn im umzuset- 
zenden Befehl eine Konstante enthalten ist, nach einem die Konstante enthaltenden Konstanten-Speicherbereich ge- 
sucht wird und dann, wenn ein solcher Konstanten-Speicherbereich gefunden wurde, dieser Konstanten-Speicher- 
bereich als Daten- und/oder Signalquelle verwendet wird. 

65 18. Verfahren nach Anspruch 17, dadurch gekennzeichnet, daB dann, wenn die Konstante nicht bereits in einem der 

vorhandenen Konstanten-Speicherbereiche gespeichert ist, die Konstante in einen neuen Konstanten-Speicher- 
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bereich gespeichert wird, unci dieser neue Konstanten-Speicherbereich als Daren- und/oder Signalquelle verwendet 
wird. 



Hierzu 8 Seite(n) Zeichnungen 
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Abstract of DE1 9843640 

The invention relates to various methods for 
configuring configurable hardware blocks. The 
methods are especially characterized by 
generation of the configuration data used to 
configure the hardware blocks. The methods 
described for generating configuration data 
enable configuration data to be generated and 
allow hardware blocks to be configured easily, 
quickly and efficiently using said configuration 
data. 
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